Rogue access point detection

ABSTRACT

A method of detecting a rogue access point is disclosed. A message is directed from a supplicant to a network through a first access point. A response message is received by the supplicant from the first access point. The supplicant can determine the first access point is a rogue access point based on whether the response message from the first access point is in nonconformity with a predetermined expectation. After the access point is determined to be a rogue access point, it is reported to the network through a valid network access point, after the supplicant is authenticated to the network.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.09/917,122 filed Jul. 27, 2001 now U.S. Pat. No. 7,181,530.

BACKGROUND OF THE INVENTION

The present invention is generally directed to the field of securitymeasures for wireless LAN technology. In a wireless local area network(or WLAN) a wireless client seeks to connect to the network in order toexchange data. There are three states in connecting to the network asspecified by the IEEE 802.11 specification for WLANs:

1. Unauthenticated and Unassociated

2. Authenticated and Unassociated

3. Authenticated and Associated.

Authentication is the process of verifying the credentials of a clientdesiring to join a WLAN. Association is the process of associating aclient with a given Access Point (AP) in the WLAN. IEEE 802.11 definestwo types of authentication methods—Open Key System Authentication andShared Key Authentication. A successful completion of the associationand authentication phases allows a WLAN node successful entry into theWLAN subsystem.

The IEEE 802.11b standard attempts to provide “privacy of a wire” usingan optional encryption scheme called “Wired Equivalent Privacy” (or WEP)in which a data frame or “payload” is run through an encryptionalgorithm, the output of which replaces the original payload. With “openkey authentication” the entire authentication process is done in cleartext. This means since the entire process is performed withoutencryption, a client can associate to the AP with the wrong WEP key orno WEP key. But as soon as the client tries to send or receive data itis denied access for not having the correct key to process the packet.With “shared key authentication” there is a challenge text packet thatis sent within the authentication process. If the client has the wrongkey or no key it will fail this portion of the authentication processand will not be allowed to associate to the AP.

This choice (open or shared key) is manually set on each device (AP andclient). There should be a match in the method chosen by the client andthe AP for the association to succeed. The default value is for openauthentication.

The entire process can be broken down into three phases:

1) Probe Phase

When a client is initialized it first sends a “probe request” packet outon all the channels. The APs that hear this packet will then send a“probe response” packet back to the station. This probe response packetcontains information such as SSID (Service Set Identifier), which theclient utilizes to determine which AP to continue the associationprocess with.

2) Authentication Phase

After the client determines which AP to continue association processwith, it begin the authentication phase based upon the probe responsepacket. This phase can be performed in either open or shared key mode.The client and the access point both have to be set-up to the sameauthentication scheme for this phase to be performed properly.

OPEN AUTHENTICATION SCHEME: The client sends an authentication requestto the AP. The AP then processes this request and determines (based onthe configured policies) whether or not to allow the client to proceedwith the association phase. The AP sends an authentication responsepacket back to the client. Based upon the type of response (pass orfail) from the AP, the client will either continue or discontinue theassociation process.

SHARED KEY AUTHENTICATION: The client sends an authentication request tothe AP. The AP processes this request, generates and sends a challengetext packet to the client. The client is then required to encrypt thepacket utilizing its already-configured WEP key and send the packet backup to the AP. The AP then determines if it can decipher the packetcorrectly. Based upon this test, the AP will send either a pass or failin the authentication response packet to the client that determines ifthe client is allowed to continue the association phase or not.

3) Association Phase

When the client successfully completes the authentication phase (forexample, receives a successful authentication response packet from theAP), it proceeds to the association phase. The client sends anassociation request packet to the AP. The AP analyses the information inthis packet and if it passes, the AP adds the client to its associationtable. It then sends an association response packet to the client, whichcompletes the association phase.

OVERVIEW OF EXAMPLE EMBODIMENTS

Still other objects of the present invention will become readilyapparent to those skilled in this art from the following descriptionwherein there is shown and described a preferred embodiment of thisinvention, simply by way of illustration of at least one of the bestmodes best suited to carry out the invention. As it will be realized,the invention is capable of other different embodiments and its severaldetails are capable of modifications in various obvious aspects allwithout departing from the invention. Accordingly, the drawing anddescriptions will be regarded as illustrative in nature and not asrestrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings incorporated in and forming a part of thespecification, illustrates examples of the present invention, andtogether with the description serve to explain the principles of theinvention.

FIGS. 1 and 2 illustrate a network authentication arrangement inaccordance with the present invention.

FIGS. 3 through 7 depict steps in the authentication process inaccordance with the present invention.

FIG. 8 illustrates an example of a methodology for rogue access pointdetection.

DESCRIPTION OF EXAMPLE EMBODIMENTS

This description provides examples not intended to limit the scope ofthe invention, as claimed. The figures generally indicate the featuresof the examples, where it is understood and appreciated that likereference numerals are used to refer to like elements.

An example embodiment contemplates a flexible security framework tosupport enhancements that would overcome the disadvantages of previoussystems. Cisco, Microsoft and several other vendors have endorsed therole of the developing IEEE 802.1X standard as the preferred frameworkfor edge security and are actively participating in the standardizationefforts to foster interoperable implementations. The IEEE 802.1X WorkingGroup is chartered with the goal of providing an interoperable securityframework for port based access control that resides in the upper layers(for example, above the MAC layer). The primary philosophy for the portbased access control layer is to enable the plug-in of newauthentication schemes and key management methods without changingswitches, NICs, Access Points, and so on. Another goal is to alsoleverage the main CPU resources for cryptographic calculations. Thissecurity philosophy is intended to provide end users and customers withdecreased hardware cost and complexity, to enable customers to choosetheir own security solution, to permit the implementation of the latest,most sophisticated authentication and key management techniques withmodest hardware, and to enable rapid development response to securityissues.

When a host connects to the LAN port on a 802.1X switch and AccessPoint, the authenticity of the host is determined by the switch portaccording to the protocol specified by 802.1X, before the servicesoffered by the switch are made available on that port. Until theauthentication is complete, only EAPOL (see below) frames are allowed tobe sent and received on that port. Once the host authentication issuccessful, the port switches traffic as a regular port. As an example,when a Windows 2000 PC is hooked on to a LAN switch port, and when auser logs in, the switch sends a message requesting the PC to identifyitself. When the PC responds back with an identity frame, the switchmakes use of the service of an authentication server to verify thecredentials of the user. If the authentication server informs the switchthat the user is authentic, then the switch opens its port for providingthe network services of the switch.

As used herein and as shown in FIG. 1, a “port” is a single point ofattachment to the LAN infrastructure—for example, ports of MAC Bridges.A “Port Access Entity” (PAE) operates the algorithms and protocolsassociated with the authentication mechanisms for a given port of thesystem. An “authenticator PAE” 10 is an access point that wishes toenforce authentication before allowing access to services that areaccessible via that port. The authenticator PAE 10 is responsible forcommunication with the supplicant, and for submitting the informationreceived from the supplicant to a suitable authentication server inorder for the credentials to be checked and for the consequentauthorization state to be determined. The functionality of authenticatorPAEs is independent of the actual authentication method. It merely actsas a pass-through for the authentication exchange, for example, a switchport. The “supplicant PAE” 12 is a PAE that wishes to access theservices accessible via the authenticator. The supplicant PAE isresponsible for responding to requests from the authenticator 10 forinformation that will establish its credentials, for example, anend-user PC, e.g. a Windows 2000 PC connected to the LAN switch port. An“authentication server” 14 verifies the credentials of the supplicant12. It indicates in response whether or not the supplicant 12 isauthorized to access the authenticator's services. It basically providesthe authentication service for the authenticator PAE 10 that acts as aclient, for example, a RADIUS server.

The IEEE 802.1X standard makes authentication more generic rather thanenforcing a specific mechanism on the devices. 802.1X makes use ofExtensible Authentication Protocol (EAP) for communication information.The 802.1X standard defines a standard for encapsulating the ExtensibleAuthentication Protocol messages to that they can be handled directly bya LAN MAC service. This encapsulated form of an EAP frame is known as anExtensible Authentication Protocol Over LAN (EAPOL) frame and is definedin the standard. Alternatively, with Extensible Authentication ProtocolOver Wireless (EAPOW), the EAPOL messages described earlier areencapsulated over 802.11 wireless frames. The packet exchange for anIEEE 802.1X conversation using EAP is highlighted in FIG. 2. Thesemessages are a sub set of the 802.1X for 802.11 implementation describedbelow since there is no WEP key required for wired 802.1X networks.

The EAP protocol described above was originally designed to provide anextensible method for a “point-to-point protocol” (PPP) server toauthenticate its clients and possibly for the client to authenticate theserver. The protocol describes an extensible packet exchange to allowthe passing of authentication information between the client and the PPPserver. Normally PPP servers rely on a centralized authentication serverto validate the clients on their behalf. One of the more popular typesof servers is a RADIUS server. Extensions to the RADIUS protocol havebeen contemplated to allow the passing of the EAP packets between theauthentication server and the PPP server. In this case the PPP server isjust a relay agent with the authentication conversation happeningbetween the client and the RADIUS server. The RADIUS server informs thePPP server of the result of the authentication and whether to allow theclient to access the network.

It has been contemplated to adapt EAP to WLANs using Public KeyInfrastructure (PKI) with EAP-TLS as the authentication method. However,PKI schemes are very compute-intensive on the client systems, requirecareful planning and design of the overall architecture, and the overallsolution costs may be prohibitive for typical enterprises. The onlyother defined authentication method EAP-MD5 was inadequate, as it doesnot support mutual authentication between the client and theauthentication server.

The EAP protocol was designed so that any type of network access servercould use it to validate its clients. In the case of a wireless accesspoint the link to its radio client is not a PPP link but a WLAN. TheIEEE 802.1X EAP over LAN (EAPOL) specification defines a method forencapsulating EAP packets in either Ethernet or token ring packets suchthat they may be transmitted over a LAN. The 802.11 specification alsoallows for data traffic between the client and access point to beencrypted using a WEP encryption key. In early implementations, theaccess point would have a single key, which had to be programmed intoeach client radio and all traffic in the wireless cell would beencrypted with the single key.

An example embodiment includes a newly-developed protocol called the“light extensible authentication protocol” (EAP-Cisco Wireless or“LEAP”) authentication type. By using EAP authentication, the client andRADIUS server have a shared secret, usually a username and passwordcombination. The RADIUS can pass enough information to the access pointsuch that the client and access point may independently derive anencryption key that is unique for this client-access point pair.EAP-Cisco Wireless offers the following benefits: requires minimalsupport from the client CPU while offering mutual authentication;support for embedded systems, such as printers; support for hostmachines running operating systems that did not have the support fornative EAP or routines to allow the use of the PKI authentication; andsupport for all popular operating systems such as Windows 95, Windows98, Windows NT, Windows 2000, Windows Millennium, Windows CE, Linux andMac OS 9.X.

As shown in FIG. 3, the EAP-Cisco Wireless implementation in accordancewith a particular embodiment comprises three components described asfollows. A EAP-Cisco Wireless supplicant 22 is provided, available as adriver update for Windows 95, 98, NT, 2000, Windows Millennium, WinCE,Linus and Mac OS 9.X. This EAP-Cisco Wireless supplicant 22 can be apiece of client software and firmware that resides on the host PC withthe WLAN adapter. The EAP-Cisco Wireless supplicant 22 can be set-up toeither have the username and password stored in the WLAN NIC card or tohave it be manually entered via a network logon process. An 802.1X for802.11 authenticator 20 is provided to be available as a software updatefor Cisco 340 series and newer access points. A EAP-Cisco Wirelessauthentication server 24 is a RADIUS Server that implements EAP-CiscoWireless authentication, such as Cisco Secure Access Control Server(ACS) Version 2.6. The entire authentication and key distributionprocess is accomplished in three phases, Start, Authenticate and Finishas illustrated in FIG. 3.

FIGS. 4 through 7 summarize the different packet exchanges for eachphase between the EAP-Cisco Wireless supplicant 22, the access pointauthenticator 20, and the EAP-Cisco Wireless-RADIUS server 24. FIG. 4shows an 802.1X over 802.11 exchange using the EAP-Cisco Wirelessauthentication protocol.

The start phase of EAP-Cisco Wireless Authentication is shown in FIG. 4.In the start phase the following packets are exchanged between theentities. The EAPOW-Start (or EAPOL-Start in 802.1X for Wired networks)is used to start the authentication process and is directed by theclient/supplicant 22 to the AP/authenticator 20, in accordance with802.1X. The EAP-Request/Identity is used by the AP/Authenticator 20 torequest the client's/supplicant's identity, in accordance with themessage definition in RFC 2284. The EAP-Response/Identity is used by theclient/supplicant 22 to deliver the identifying user name and passwordto the AP/Authenticator 20, in accordance with the definition in RFC2284.

The Authenticate Phase of EAP-Cisco Wireless Authentication is shown inFIG. 5. The authenticate sequence can vary based on the mutualauthentication method chosen between the client 22 and theauthentication server 24. For example, with the present EAP-CiscoWireless authentication, the sequence of messages occurs as described inthe example embodiment of FIG. 5. In the example embodiment as shown inFIG. 6, the EAP-Response/Identity message from the client/supplicant 22is forwarded to the RADIUS server 24 by the AP 20 in the form of aRADIUS-Access-Request with EAP extensions, in which EAP is encapsulatedin the RADIUS protocol. The RADIUS server 24 then responds back to theaccess-request with a RADIUS-challenge, which then gets responded to bythe client 22, in accordance with the RADIUS protocol described in RFC2138. The present EAP-Cisco Wireless authentication is a mutualauthentication method with the access point 20 in the middle actingsolely as a transport vehicle. For example, the access point 20 in theauthenticate phase moves the contents of the packets from EAP to RADIUSand vice versa. In this way, no logon functions are performed throughthe AP, thereby precluding network access to rogue APs.

Alternately, the present invention can support other message types, suchas Transport Level Security (TLS) as described in RFC2286 to transfercertificates in a PKI implementation, in which EAP-TLS described inRFC2716 messages would be used. Other such message types can also beused without departing from the invention.

The finish phase of the present EAP-Cisco Wireless Authentication isshown in FIG. 7. If the user is discovered to be invalid, the RADIUSserver 24 sends a RADIUS deny packet with an embedded EAP fail. If theuser is discovered to be valid, the server 24 sends aRADIUS-Access-Accept packet with an EAP success attribute. TheRADIUS-Access-Accept message also contains the MS-MPPE-Send-Keyattribute defined by RFC2548 to the access point 20. The key needs to besent to the access point 20 in order for it to obtain the session keythat the client 22 will be using to talk with it. Both the client 22 andthe RADIUS server 24 who are using the EAP-Cisco Wireless authenticationderive the session key from the user's password. The IEEE 802.11'sencryption may be based on a 40/64-bit or 104/128-bit key. The keyderivation routines provide a key longer than needed. When the accesspoint 20 receives the key from the RADIUS server 24 (via theMS-MPPE-Send-Key attribute) it sends an EAPOL-KEY message to the client22 supplying the key length and key index to use. The key value (oractual WEP key) is not sent since the client 22 has already derived iton its own using preloaded algorithms and reference data correspondingto those preloaded into the authentication server. The packet isencrypted using the full-length derived key. The access point 20 alsosends an EAPOL-KEY message supplying the length, key index and value ofthe multicast/broadcast key. This packet is also encrypted using thefull-length derived session unicast key. This completes the entiremutual authentication and key derivation and transfer between theEAP-Cisco Wireless Authentication Server 24 and the EAP-Cisco WirelessSupplicant 22. Thus, the intermediary access points 20 only pass theencrypted packets, and do not “share the secret,” i.e. do not possessthe means to decrypt the packets. In this way, the clients of the WLANhave become invulnerable to rogue AP attacks.

The example embodiment is particularly useful for detecting rogue accesspoints that may seek to access the network. During the start phase ofauthentication, the client/supplicant 22 directs a packet to thenetwork, e.g. the server 24, through the AP/authenticator 20. A networkresponse packet is received by the client/supplicant 22 from thenetwork, through the AP/authenticator 20. In order to detect a rogueaccess point, the client/supplicant 22 performs a routine of determiningwhether the access point 20 is a valid network access point or a rogueaccess point. This determination is based on whether the receivednetwork response packet is in conformity or nonconformity withpredetermined expectations. The “predetermined expectations” can includethe “shared secret” information disclosed hereinabove or any otherstandard applied for determining conformity.

In an example embodiment, a valid network access point 20 conforms withexpectations if it forwards data traffic from the network conformingwith IEEE 802.1X standards. If the forwarded data traffic is determinedby the client/supplicant 22 to not conform, the access point isdetermined to be a rogue access point. Further, in another preferredembodiment, a valid network access point 20 is determined to conformwith predetermined expectations if the mutual authentication disclosedhereinabove is successful. Non-conformity is determined by the failureof the mutual authentication. After issuing a challenge from the server24 to the client 22, the client 22 issues a counter-challenge back tothe server 24. If the counter challenge fails, the access point isidentified as a rogue AP.

If an access point is determined to be a rogue access point, it isreported as such to the network. In one aspect, the rogue access pointis reported to the network by the client 22 through a valid networkaccess point 20, at a later time after the client 22 has contacted avalid AP and authenticated to the network.

The EAP-Cisco Wireless Authentication and Key distribution can bedeployed in a large campus. EAP-Cisco Wireless supplicant or clientsoftware that can be supported by a variety of operating systems,including Windows 95, Windows 98, Windows NT 4.0, Windows 2000, WindowsMillennium, WinCE 3.0, Mac OS 9.x, and any other type of platform thatmay be commonly used. The client authentication can be set-up to work inthe default open/shared-key modes defined by the standards or inEAP-Cisco Wireless mode.

In view of the foregoing structural and functional features describedabove, a methodology 800 in accordance with various aspects of thepresent invention will be better appreciated with reference to FIG. 8.While, for purposes of simplicity of explanation, methodology 800 ofFIG. 8 is shown and described as executing serially, it is to beunderstood and appreciated that the present invention is not limited bythe illustrated order, as some aspects could, in accordance with thepresent invention, occur in different orders and/or concurrently withother aspects from that shown and described herein. Moreover, not allillustrated features may be required to implement a methodology inaccordance with an aspect the present invention. Embodiments of thepresent invention are suitably adapted to implement methodology 800 inhardware, software, or a combination thereof.

At 802, a mobile node (e.g. a wireless client) initiates communicationwith a network through an access point. The mobile node may beassociating with a network that the mobile node has not previouslyassociated with (such as for example when powering up), or the mobilenode may be initiating a roam to a new access point. This couldcorrespond to the start phase of an authentication and key distributionprocess as illustrated in FIG. 3. For example, the mobile node may sendan EAPOL-START message as illustrated in FIG. 2 or an EAPOW-STARTmessage as illustrated in FIG. 4.

In an example embodiment described herein supra, the client andauthentication server have a ‘shared secret’ such as a usemame andpassword combination, no logon functions are performed by the AP. Thus,a rogue AP that is not coupled to the authentication server would beunable to provide an appropriate response to EAP (or LEAP) compatibletype messages, such as for example an EAP or LEAP message that requiresknowledge of the shared secret, because a rogue AP will not have accessto the ‘shared secret.’ A malicious rogue AP, that is a rogue AP that islistening to wireless traffic to acquire information, may be able toprovide some responses to EAP or LEAP messages, for example sending anEAP-REQUEST/IDENTITY responsive to an EAPOL (or EAPOW)-START message,but would not be able to mutually authenticate with a mobile nodebecause it lacks access to the shared secret.

At 804, the mobile node receives a response from the network. In anexample embodiment, the mobile node would expect to receive one or moreof a EAP-REQUEST IDENTITY (as illustrated in FIGS. 2 and 4) and anEAP-REQUEST (as illustrated in FIGS. 2 and 5).

In an example embodiment, the mobile node may receive an EAP-SUCCESSmessage as illustrated in FIG. 5. Upon receiving an EAP-SUCCESS message,the mobile node may challenge the server as illustrated in FIG. 5. Forexample, the mobile node may send an EAP-REQUEST containing a LEAPchallenge. The mobile node would anticipate receiving an EAP-RESPONSEcontaining a LEAP challenge response as illustrated in FIG. 5.

At 806, the mobile node determines whether the response received fromthe access point is a valid response. For example, if the mobile nodeinitially sent an EAPOL-START packet to the network through the AP, anEAP-REQUEST/IDENTIY response would be expected as illustrated in FIGS. 2and 4. If the response is not an EAP-REQUEST/IDENTITY, or theEAP-REQUEST/IDENTITY is improperly formatted, the mobile node candetermine that the AP is a rogue AP.

In the example embodiment where a proper EAP-REQUEST/IDENTITY isreceived, the mobile node could respond with an EAP-RESPONSE/IDENTITY.The mobile node would expect to receive an EAP-REQUEST, as illustratedin FIGS. 2, 5 and 6. If the mobile node does not receive an EAP-REQUESTor the EAP-REQUEST is improperly formatted, the mobile node candetermine the AP is a rogue AP.

After sending an EAP-RESPONSE to the EAP-REQUEST, the mobile node wouldexpect to receive an EAP-SUCCESS. If the mobile node does not receive anEAP-SUCCESS or the EAP-SUCCESS is not properly formatted, the mobilenode can determine that the AP is a rogue AP.

If the mobile node receives an EAP-SUCCESS message, then the mobile nodecan send a challenge the authentication server as illustrated in FIG. 5.For example, the mobile node can send an EAP-REQUEST containing a LEAPchallenge. A rogue AP not in communication with a server with the‘shared secret’ is unable to provide a proper response.

If the AP is a valid AP, it would send the request to the authenticationserver (as illustrated a RADIUS-ACCESS-REQUEST containing LEAP challengeis sent from the AP to the RADIUS server). The mobile node shouldreceive an EAP-RESPONSE containing LEAP challenge response from the AP.If the response is invalid, the mobile node can determine that the AP isa rogue AP (e.g. the AP is not in communication with the RADIUS server).

If at 806, the mobile node determines that the AP is a rogue AP (NO),the mobile unit remembers the invalid AP, e.g. stores data about thepotentially rogue AP. In an example embodiment the data can include anidentifier for the AP (e.g., the BSSID) and the reason for determiningthe AP was a rogue AP (e.g., invalid, or no, response to an EAP-STARTmessage). At 808 the mobile node begins searching for another AP tocommunicate with the network. Upon roaming to another AP, the mobilenode initiates communication with the network at 802 and steps 804 and806 are also repeated.

If at 806, the mobile node determines that the responses from the AP arevalid. the mobile node determines that the AP is a valid AP (YES). Themobile completes associating with the AP and begins a session with AP at812. If prior to associating with the valid AP the mobile node detecteda rogue AP, at 814 the mobile node reports the rogue AP to the networkthrough the valid AP.

1. A method, comprising: initiating, via a client device, a firstcommunication to an authentication server through a first access point;determining, by the client device, the first access point is a rogueaccess point based on receiving an invalid response to the firstcommunication from the first access point; storing, in a memoryassociated with the client device, data representative of the firstaccess point and the received invalid response; initiating, via theclient device, a second communication to the authentication serverthrough a second access point; determining, by the client device, thesecond access point is a valid access point based on receiving a validresponse to the second communication; and reporting the first accesspoint is a rogue access point by the client device through the secondaccess point in accordance with the data stored in the memory associatedwith the client device.
 2. The method of claim 1, the firstcommunication further comprising authenticating a supplicant to anetwork.
 3. The method of claim 2, the first communication furthercomprising performing a mutual authentication by sending a challengepacket to the authentication server.
 4. The method of claim 3, the firstcommunication further comprising authenticating a supplicant to anetwork.
 5. The method of claim 4, the first communication furthercomprising performing a mutual authentication by sending a challengepacket to the authentication server.
 6. The method of claim 1 whereinthe predetermined expectations comprise data traffic conforming withIEEE 802.1X standards.
 7. The method of claim 1, the first communicationfurther comprises a mutual authentication to a network; and thedetermining the first access point is a rogue access point is responsiveto a failure of the mutual authentication.
 8. The method of claim 7, thefirst communication comprises issuing a challenge to an authenticationserver; and the determining the first access point is a rogue accesspoint is responsive to determining the response received from the firstaccess point is not proper based on a shared secret between a supplicantand the authentication server.
 9. The method of claim 8 wherein theshared secret is a username and password.
 10. The method of claim 9, theresponse to the first communication comprises a key index; and thedetermining the first access point is a rogue access point is responsiveto the first access point using an encryption key that does not match anencryption key derived from the key index.
 11. The method of claim 10wherein the encryption parameters are based on one of a group consistingof a 40/64-bit and a 104/128-bit key.
 12. The method of claim 1, thefirst communication comprises one of a group consisting of an EAP-STARTcompatible message, an EAPOL-START compatible message, and anEAPOW-START compatible message; and the determining the first accesspoint is a rogue access point is based on receiving an invalid responseto the one of a group consisting of an EAP-START compatible message, anEAPOL-START compatible message, and an EAPOW-START compatible message.13. An apparatus, comprising: a wireless client operable to communicatewith wireless access points; the wireless client is configured toinitiate a first communication to an authentication server through afirst access point; the wireless client is operable to determine thefirst access point is a rogue access point based on receiving an invalidresponse to the first communication from the first access point; thewireless client is operable to store data representative of the firstaccess point and the received invalid response in an associated memory;the wireless client is operable to initiate a second communication tothe authentication server through a second access point; the wirelessclient is operable to determine the second access point is a validaccess point based on receiving a valid response to the secondcommunication; and the wireless client is configure to report the firstaccess point is a rogue access point through the second access pointafter determining the second access point is a valid access point inaccordance with the data stored in the memory associated with thewireless client.
 14. The apparatus of claim 13, the first communicationfurther comprises sending a challenge packet to the authenticationserver.
 15. The apparatus of claim 14, the wireless client determinesthe first access point is a rogue access point responsive to an invalidresponse to the challenge packet.
 16. The apparatus of claim 14, thewireless client is operable to determine the first access point is arogue access point responsive to determining the response to thechallenge packet received from the first access point is invalid properbased on a shared secret between the wireless client and theauthentication server.
 17. The apparatus of claim 16, wherein the sharedsecret is a username and password.
 18. The apparatus of claim 13,response to the first communication comprises a key index; and thewireless client is operable to determine the first access point is arogue access point responsive to the first access point using anencryption key that does not match an encryption key derived from thekey index.
 19. An apparatus, comprising: means adapted for initiating afirst communication to an authentication server through a first accesspoint; means adapted for determining the first access point is a rogueaccess point based on receiving an invalid response to the firstcommunication from the first access point; means adapted for storingdata representative of the first access point and the received invalidresponse; means adapted for initiating a second communication to theauthentication server through a second access point; means adapted fordetermining the second access point is a valid access point based onreceiving a valid response to the second communication; and meansadapted for reporting the first access point is a rogue access pointthrough the second access point responsive to the means adapted fordetermining the second access point is a valid access point inaccordance with the stored data.
 20. The apparatus according to claim19, further comprising: the means adapted for initiating a firstcommunication further comprises means adapted for sending a challenge tothe authentication server; and the means adapted for determining thefirst access point is a rogue access point is responsive to receiving aninvalid response to the challenge to the authentication server; whereinthe challenge is based on a shared secret with the authenticationserver.